Method and system for in-place updating content stored in a storage device

ABSTRACT

Method and system for updating a stored version of content stored in a storage device using an update package. The update package that includes update commands is adapted for updating an original version of content to an updated version. The updating is carried out in accordance with an update sequence. The method includes determining direction of the updating. If the direction is indicative of forward then the method forward-updates the stored version to the updated version in accordance with the update sequence. If the direction is indicative of roll-back, the method generates a roll-back update sequence opposite to the update sequence and rolls-back the stored version to the original version in accordance with the roll-back update sequence.

FIELD OF THE INVENTION

This invention relates to updating a stored version of content stored ina storage device using an update package. More specifically, thisinvention relates to in-place updating.

BACKGROUND OF THE INVENTION

Sometimes it is required to update content stored in a storage device.For example, if the content is a software (such as an executable file),it is sometimes required to upgrade the software. However, it should benoted that sometimes other types of content also require updates, suchas text or data stored in a database, etc. Hereinafter the term “oldversion” or “original version” refers to content before update, the term“new version” or “updated version” refers to the content after it wasupdated. An “update package”, sometimes referred to also as a“difference”, a “difference result” or a “delta”, includes data providedas input for an update process, wherein the update process updates theold version to the new version in accordance with the update package.

There are several ways known in the art for generating update packagesand using them for updating versions. For example, U.S. Pat. No.6,546,552 (“Difference extraction between two versions of data-tablescontaining intra-references”, published 2003) discloses a method forgenerating a compact difference result between an old program and a newprogram. Each program includes reference entries that contain referencesthat refer to other entries in the program. According to the method ofU.S. Pat. No. 6,546,552, the old program is scanned and for eachreference entry, the reference is replaced by a distinct label mark,whereby a modified old program is generated. In addition, according toU.S. Pat. No. 6,546,552, the new program is scanned and for eachreference entry, the reference is replaced by a distinct label mark,whereby a modified new program is generated. Thus, utilizing directly orindirectly the modified old program and modified new program, thedifference result is generated.

WO 2004/114130 (“Method and system for updating versions of contentstored in a storage device”, published 2004) discloses a system andmethod for generating a compact update package between an old version ofcontent and a new version of content. The system of WO 2004/114130includes a conversion element generator for generating a conversionelement associated with the old version and new version. It alsoincludes a modified version generator for generating a modified version,and an update package generator for generating the compact updatepackage. The compact update package includes the conversion element anda modified delta based on the modified version and the new version.

WO 2005/003963 (“Method and system for updating versions of contentstored in a storage device”, published 2005) discloses a system andmethod for updating versions of content stored in a storage device. Thesystem of WO 2005/003963 includes an update module for obtaining aconversion element and a small delta. It also includes a converted olditems generator for generating converted old items by applying theconversion element to items of an old version, a data entries generatorfor generating data entries based on the modified data entries and onthe converted old item, and a new version generator for generating a newversion of content by applying the commands and the data entries to theold version.

U.S. Pat. No. 6,832,373 (“System and method for updating anddistributing information”, published 2004) discloses devices, systemsand methods for updating digital information sequences that arecomprised by software, devices, and data. In addition, these digitalinformation sequences may be stored and used in various forms,including, but not limited to files, memory locations, and/or embeddedstorage locations. Furthermore, the devices, systems, and methodsdescribed in U.S. Pat. No. 6,832,373 provide a developer skilled in theart with an ability to generate update information as needed and,additionally, allow users to proceed through a simplified update path,which is not error-prone, and may be performed more quickly than throughthe use of technologies existing when U.S. Pat. No. 6,832,373 was filed.

It is known to those versed in the art that content can be stored in astorage device, such as disk or memory, while some storage devices areorganized in blocks. Blocks being part of the original version arereferred to as “old blocks” or “original blocks”, while blocks beingpart of an updated version are referred to as “new blocks” or “updatedblocks”. In addition, when updating an original version forming anupdated version thereby, the updated version can sometimes use contentpreviously stored in blocks of the original version. That is, thecontent of updated blocks is sometimes similar to content of originalblocks.

Furthermore, available storage devices can have a limited space. Thus,while updating versions in a storage device, it is sometimes preferredto store the new version in place of the old version, saving spacethereby. Such an update process, where the new version occupies at leastsome of the space previously occupied by the old version, is referredto, in the art as “in-place update” or “updating in-place”.

It should be noted that an update process can process the blocks of theold version in an order which does not necessarily correspond to thesequential order of the blocks within the file. The order, in accordancewith which blocks of the old version are updated, is referred to as an“update sequence” or “update order”.

One of the outcomes of in-place updating is that, once storage blockshave been updated, the content of at least some of them being part ofthe original version (i.e., at least part of the original content), ispotentially lost. Therefore, once the process of updating has startedand after some original blocks are modified to hold updated content (theupdated content being part of the updated version), the storage devicecan store content which is partly original and partly updated version.

In addition, it is known in the art that the old content is sometimesrequired for the update process, such as in a delta update method.Therefore, if the update process is interrupted through the course ofits running, before the creation of the new version is completed andwhen the stored content (or stored version) is partly old version andpartly new version, the in-place update process cannot be repeated fromstart anymore.

In light of the above, it is realized that in-place updating can besensitive to interruptions. When the process of in-place updating triesto resume from the point where it was interrupted (the resume location),it requires information that allows calculation of the location ofinterruption. After locating the location of interruption, the updateprocess may also need to restore other information, which was availableto the interrupted process at the time of interruption.

Currently in the art, a record referred to hereinafter as “state record”is commonly used for storing results of calculations calculated beforethe interruption. The results, together with the identification of thecurrent updated block form a “state” of the in-place update process. Forexample, if the update package is compressed and it is beingdecompressed on-the-fly during the update process for reading just thenecessary parts for updating each old block, and were the amount of datadecompressed from the update package, depends on old contents of updatedblocks, then this amount cannot be re-computed again once blocks wereactually updated.

As mentioned already above, the process cannot restart from itsbeginning. Therefore, it might be that some of the data in the staterecord cannot be re-computed even if the last updated record is known—itneeds to be restored by other means. The common practice in the priorart is to maintain a state-record as mentioned above in a storage deviceaccessible to the update process, and to update it periodically duringthe update process, to reflect its progress, an operation referred tohereinafter as “state recording”. Using state recording enables theresumption of an in-place update process by re-constructing the state ofthe process as it was at the last successful update operation, and tocontinue the process towards its completion.

In some cases, the information stored during state recording cannot bepart of the contents being updated and must be separated to another areaof storage. State recording takes time since it involves read & writeoperations from and to the storage device. In some case, where the read& write operations of the storage device are allowed only for wholeblocks, the time required for the whole process is doubled—for eachupdated block there is another block to update—the one holding thestate's recording.

It is also known to those versed in the art that, in order to properlyresume an interrupted in-place update process, there may also be theneed to handle a corrupted block which was the result of an interruptedstorage write operation. It could be impossible to restore theinformation in that block, as the block's old content was modified andthere may be no way to restore its old content just by examining thefile's other blocks. This problem is resolved by the prior art by usinga backup buffer where any block's new content is being stored therefirst and then copying its content to its target block to be updated(hereinafter referred as “update-first”) or alternatively, the old blockis copied to a backup buffer and afterwards the new content is generatedand stored in its target block (hereinafter referred as “backup-first”).This method is also known in the art as “2-phase commit” scheme.

Updating software of embedded devices such as mobile telephones is anexample for an in-place update procedure. It is realized that storage ofmobile telephones can be limited. For example, a mobile telephone canhave enough storage to hold only one version of its software (alsocalled firmware). Maintaining state-recording inside blocks of thefirmware itself is clearly not practical, since it would interfereheavily with the process of creating the software and therefore it mustbe stored in a separate area of storage. Updating mobile phone'sfirmware is a relatively slow process due to the speed of the storagedevices used (Flash memory). During the update process the phone isinoperable, creating the need to minimize the time it takes.

There is a need in the art for faster and reliable updating procedures,allowing shorter interruptions in embedded devices operation duringsoftware update.

There is a need in the art to provide for a new method and system forupdating versions of content stored in a storage device.

SUMMARY OF THE INVENTION

It is therefore an object of the invention to provide a new method andsystem for updating versions of content stored in a storage device.

By one embodiment, the invention provides a method for updating a storedversion of content stored in a storage device using an update package,wherein the update package is adapted for updating an original versionof content to an updated version, wherein the update package includesupdate commands and wherein the updating is carried out in accordancewith an update sequence, the method comprising: determining direction ofthe updating including: if the direction is indicative of forward thenforward-updating the stored version to the updated version in accordancewith the update sequence; and if the direction is indicative of rollbackgenerating a roll-back update sequence opposite to the update sequenceand rolling-back the stored version to the original version inaccordance with the roll-back update sequence.

By a further embodiment, the invention provides a method for reversingan update process, the update process is adapted for updating a storedversion of content stored in a storage device to one of a groupincluding an updated version and an original version using an updatepackage, the method comprising: reversing update commands in the updatepackage that were previously performed during updating.

By a still further embodiment, the invention provides a method forin-place updating a stored version of content stored in a storage deviceusing an update package, wherein the update package is adapted forupdating an original version of content to an updated version, themethod comprising: determining direction of the updating; and if thedirection is indicative of forward then forward-updating the storedversion to the updated version; otherwise rolling-back the storedversion to the original version.

By another embodiment, the invention provides a method for providing anupdate process of a stored version, comprising: providing a forwardupdate for updating the stored version to a first version; providing aroll-back update for updating the stored version to a second version;applying a first update operation being either of said forward updateand said roll-back update; and applying a second update operation beingeither of said forward update and said roll-back update and being otherthan said first update operations.

By yet another embodiment, the invention provides a method for providingan update process of a stored version, comprising: applying a roll-backupdate for updating the stored version to an original version.

By yet another embodiment, the invention provides a system for updatinga stored version of content stored in a storage device using an updatepackage, wherein the update package is adapted for updating an originalversion of content to an updated version, wherein the update packageincludes update commands and wherein the updating is carried out inaccordance with an update sequence, the system comprising: a directiondetermination unit adapted for determining direction of the updating aforward updating processor coupled to the direction determination unitfor forward-updating the stored version to the updated version inaccordance with the update sequence when the direction of the updatingis indicative of forward; a roll-back sequence generator coupled to thedirection determination unit for generating a roll-back update sequenceopposite to the update sequence when the direction of the updating isindicative of roll-back; and a roll-back updating processor coupled tothe roll-back sequence generator for rolling back the stored version tothe original version in accordance with the roll-back update.

By yet another embodiment, the invention provides a system for reversingan update process, the update process is adapted for updating a storedversion of content stored in a storage device to one of a groupincluding an updated version and an original version using an updatepackage, the system comprising: an update commands reversal unit forreversing update commands in the update package that were previouslyperformed during updating.

By yet another embodiment, the invention provides a system for in-placeupdating a stored version of content stored in a storage device using anupdate package, wherein the update package is adapted for updating anoriginal version of content to an updated version, the systemcomprising: a direction determination unit adapted for determiningdirection of the updating; a forward updating processor coupled to thedirection determination unit for forward-updating the stored version tothe updated version when the direction is indicative of forward; and aroll-back updating processor coupled to the direction determination unitfor rolling-back the stored version to the original version when thedirection is indicative of roll-back.

Still by a further embodiment, the invention provides a program storagedevice readable by machine, tangibly embodying a program of instructionsexecutable by the machine to perform a method for updating a storedversion of content stored in a storage device using an update package,wherein the update package is adapted for updating an original versionof content to an updated version, wherein the update package includesupdate commands and wherein the updating is carried out in accordancewith an update sequence, the method comprising: determining direction ofthe updating including: if the direction is indicative of forward thenforward-updating the stored version to the updated version in accordancewith the update sequence; and if the direction is indicative ofroll-back generating a roll-back update sequence opposite to the updatesequence and rolling-back the stored version to the original version inaccordance with the roll-back update sequence.

Still by a further embodiment, the invention provides a computer programproduct comprising a computer useable medium having computer readableprogram code embodied therein for updating a stored version of contentstored in a storage device using an update package, wherein the updatepackage is adapted for updating an original version of content to anupdated version, wherein the update package includes update commands andwherein the updating is carried out in accordance with an updatesequence, the computer program product comprising: computer readableprogram code for causing the computer to determine direction of theupdating including: computer readable program code for causing thecomputer to forward-update the stored version to the updated version inaccordance with the update sequence if the direction is indicative offorward; and computer readable program code for causing the computer togenerate a roll-back update sequence opposite to the update sequence androlling-back the stored version to the original version in accordancewith the roll-back update sequence if the direction is indicative ofroll-back.

Still by a further embodiment, the invention provides a program storagedevice readable by machine, tangibly embodying a program of instructionsexecutable by the machine to perform a method for reversing an updateprocess, the update process is adapted for updating a stored version ofcontent stored in a storage device to one of a group including anupdated version and an original version using an update package, themethod comprising: reversing update commands in the update package thatwere previously performed during updating.

Still by a further embodiment, the invention provides a computer programproduct comprising a computer useable medium having computer readableprogram code embodied therein for reversing an update process, theupdate process is adapted for updating a stored version of contentstored in a storage device to one of a group including an updatedversion and an original version using an update package, the computerprogram product comprising: computer readable program code for causingthe computer to reverse update commands in the update package that werepreviously performed during updating.

Still by a further embodiment, the invention provides a program storagedevice readable by machine, tangibly embodying a program of instructionsexecutable by the machine to perform a method for in-place updating astored version of content stored in a storage device using an updatepackage, wherein the update package is adapted for updating an originalversion of content to an updated version, the method comprising:determining direction of the updating; and if the direction isindicative of forward then forward-updating the stored version to theupdated version; otherwise rolling-back the stored version to theoriginal version.

Still by a further embodiment, the invention provides a computer programproduct comprising a computer useable medium having computer readableprogram code embodied therein for in-place updating a stored version ofcontent stored in a storage device using an update package, wherein theupdate package is adapted for updating an original version of content toan updated version, the computer program product comprising: computerreadable program code for causing the computer to determine direction ofthe updating; computer readable program code for causing the computer toforward-update the stored version to the updated version if thedirection is indicative of forward; and computer readable program codefor causing the computer to roll-back the stored version to the originalversion otherwise.

Still by a further embodiment, the invention provides a program storagedevice readable by machine, tangibly embodying a program of instructionsexecutable by the machine to perform a method for providing an updateprocess of a stored version, comprising: providing a forward update forupdating the stored version to a first version; providing a roll-backupdate for updating the stored version to a second version; applying afirst update operation being either of said forward update and saidroll-back update; and applying a second update operation being either ofsaid forward update and said roll-back update and being other than saidfirst update operations.

Still by a further embodiment, the invention provides a computer programproduct comprising a computer useable medium having computer readableprogram code embodied therein for providing an update process of astored version, the computer program product comprising: computerreadable program code for causing the computer to provide a forwardupdate for updating the stored version to a first version; computerreadable program code for causing the computer to provide a roll-backupdate for updating the stored version to a second version; computerreadable program code for causing the computer to apply a first updateoperation being either of said forward update and said roll-back update;and computer readable program code for causing the computer to apply asecond update operation being either of said forward update and saidroll-back update and being other than said first update operations.

Still by a further embodiment, the invention provides a program storagedevice readable by machine, tangibly embodying a program of instructionsexecutable by the machine to perform a method for providing an updateprocess of a stored version, comprising: applying a roll-back update forupdating the stored version to an original version.

By yet another embodiment, the invention provides a computer programproduct comprising a computer useable medium having computer readableprogram code embodied therein for providing an update process of astored version, the computer program product comprising:

computer readable program code for causing the computer to apply aroll-back update for updating the stored version to an original version.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to understand the invention and to see how it may be carriedout in practice, a preferred embodiment will now be described, by way ofnon-limiting example only, with reference to the accompanying drawings,in which:

FIG. 1 is a schematic illustration of a system for updating versions ina cellular network, in accordance with one embodiment of the invention;

FIG. 2 demonstrates simplified exemplary stages in updating an originalversion to an updated version;

FIG. 3 demonstrates an exemplary original version and a correspondingexemplary updated version;

FIG. 4 demonstrates exemplary update packages adapted to update theoriginal version of FIG. 3 to the updated version thereof;

FIG. 5 is a flowchart illustrating operations performed before reversingan update process, according to an embodiment of the invention;

FIG. 6 demonstrates by way of example storing deleted content, accordingto one embodiment of the invention;

FIG. 7 demonstrates by way of example reducing usage of a contentreserve buffer, according to one embodiment of the invention;

FIG. 8 is a flowchart illustrating the main procedures performed whileupdating an original version to an updated version in a reversibleupdate process, according to one embodiment of the invention;

FIG. 9 is a flowchart illustrating in detail forward-updating a storedversion, according to one embodiment of the invention;

FIG. 10 is a flowchart illustrating in detail rolling-back a storedversion, according to one embodiment of the invention;

FIG. 11 is a block diagram schematically illustrating a system forupdating a stored version of content stored in a storage device,according to one embodiment of the invention;

FIG. 12 is a block diagram schematically illustrating a system forreversing an update process, according to one embodiment of theinvention; and

FIG. 13 is a block diagram schematically illustrating a system forupdating a stored version of content stored in a storage device,according to another embodiment of the invention.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

In the following description components that are common to more than onefigure will be referenced by the same reference numerals.

Furthermore, unless specifically noted, the term “update” is usedhereinafter to refer to in-place update.

FIG. 1 is a schematic illustration of a system 101 for updating versionsin a cellular network, in accordance with one embodiment of theinvention. Cellular telephones 102 that are coupled to or includestorage devices 103, execute programs that enable their operation.Programs are normally stored in files. The version of the programcurrently executing in the cellular telephones is referred to,hereinafter, as an “old version” or as an “original version”.

It is noted that storage devices, such as the storage devices 103, aresometimes referred to also as “storage devices” or “memory units”.

Sometimes there is a need to update the programs in order for thetelephones 102 to execute a newer version thereof. Such an updatedversion is generated by an update process operating in the telephone.The update process operates in accordance with an update package(constituting a “delta file”) that the cellular telephone receives.

According to the invention, an update package is generated in an updatepackage generator 104, operating, for example, in a personal computer(PC) or in any other type of computer. The update package is stored inan update server 105 and transmitted, via a transmitter 106 to thecellular telephones 102.

It should be noted that the system 101 illustrated in FIG. 1 is anon-binding example and the invention is not limited to updatingprograms. Many other types of content stored in storage devices requireupdate, such as data stored in databases, files stored in the storagedevice etc. Therefore, hereinafter the term “content” will be usedinstead of “program”.

In the same way, the invention is not limited to cellular networksand/or to cellular telephones 102. It should be appreciated thatcellular telephones belong to a group referred to as embedded devices.There are other embedded devices, such as Personal Digital Assistants(PDAs), set-top boxes and other consumer electronic devices that arecoupled to storage devices for storing content, and sometimes it isrequired to update the content stored therein. Yet, it is possible toupdate also content stored in storage devices coupled to non-embeddeddevices, such as PCs or other computers. Therefore, the storage devices103 can be, for example, hard-disk drives, Flash-memory devices or anyother storage device.

For example, a PC, or any other computer, can store files that includedata required for its operation or for operation of programs executingtherein (such as “info files” or “dot files” known for those versed inthe art). Sometimes it is required to update this data, for example, viacommunications lines, e.g., via the internet or via any othercommunication means.

Understanding this, instead of using terms such as “telephones”, “PDAs”“consumer electronic devices”, “computer”, “PC”, etc., the term “updateddevices” will be used hereinafter, and it should be noted that the terman “update device” can refer to any device that is coupled to a storagedevice and allows updating content stored therein.

It was previously explained that in order to update content stored inthe storage devices, update packages are generated, stored in the updateserver 105 and conveyed to the storage devices or to other devicescoupled therewith (such as the cellular telephones 102). Alternatively,it is possible to convey an update package without storing it first inan update server 105. For example, it is possible to convey the updatepackage directly from the update package generator where it isgenerated. In such a case the machine where the update generatoroperates or the update generator itself is considered as the updateserver 105.

Furthermore, in the example illustrated in FIG. 1, the update package isconveyed via the transmitter 106. This is also non-binding and any otherway applicable for conveying the update package can be used. Forexample, it is possible to store the update package on a portablestorage device such as a floppy disk or disk on key thus allowing anupdated device (such as the telephones 102) to access the update packageby reading it there from.

When a cellular telephone 102 receives an update package, it can operatean update process in accordance with the update package, wherein theupdate process updates the original version for generating anotherversion referred to as an “updated version” or as a “new version”. Itshould be noted that the cellular telephone 102 can operate the updateprocess immediately after receiving the update package. Alternatively,it can store the update package in a non-volatile memory, such as in thestorage device 103, and operate the update process in some later time(such as on the next time the telephone reboots).

It is noted that a storage device can store content of original and/orupdated versions. Those versed in the art would appreciate that contentis normally stored in files, while a file, or the content stored thereinis subject to updates by an update process.

In many times a file is constituted of logically sequential content. Forexample, in a file that includes text, wherein the text is “123456789”,the character ‘2’ is logically consecutive to the character ‘1’, thecharacter ‘3’ is logically consecutive to the character ‘2’ etc.However, those versed in the art would appreciate that, when storingthis file in a storage device, it can become fragmented, i.e., differentportions of the file can be stored in different areas of the storagedevice. In other words, a logically sequential content is notnecessarily stored in a physically sequential manner in the storagedevice.

Furthermore, those versed in the art will appreciate that many storagedevices include discrete areas in them. For example, hard drives includesectors and so do flash memory modules. A discrete area in a storagedevice is referred to as a “storage block”, or shortly as “block”. It isnoted though that hard drives and flash memory modules are only twoexamples of a storage device. There are other known per se storagedevices such as Random Access Memory (RAM) etc.

Bearing in mind that a logically sequential content is not necessarilystored in a physically sequential manner in the storage device, itshould be appreciated that sequential content can be spread over severalstorage blocks. Furthermore, one storage block can include contentbelonging to several logically sequential contents (such as severalfiles). Returning now to the previous example, where the text“123456789” constitutes logically sequential content, it should beappreciated that the content “1234” can be stored in one physical block,while the content “56789” in this example can be stored in a differentphysical block that physically precedes the block where “1234” is stored(yet it is clear that logically the content “1234” precedes the content“56789”).

The Logically sequential text “123456789” will be further considered asan original version. According to the example, it is possible to updatethis file to include an updated version, wherein the text stored in theupdated version is “123756489”. In this updated version the characters‘4’ and ‘7’ were switched, compared to their position in the originalversion or in different words, in the updated version the character ‘7’replaces the character ‘4’ that appears in the original version, whilethe character ‘4’ replaces the character ‘7’. It should thus beappreciated that, in order to generate this updated version, it ispossible to divide the original version into several segments (eachsegments constitutes a “logical block”). For example, the first segmentincludes the content “123”, the second segment's content is “4”, thethird segment includes “56”, the fourth includes “7” and the fifthincludes “89”. When generating the updated version, the first, third andfifth segments are left intact, while the second and fourth segments areswitched. Thus, a segment includes logically sequential content.

It is possible to further define that segments are logically sequentialsegments of content that perform uniform behavior during update. In theexample, the segment “123” is logically sequential and it informallystays unmodified in the updated version. Similarly, the segment “7” isalso logically sequential (a sequence of 1 character is a validsequence), and it is uniformly moved to occupy the position formerlyoccupied by “4”, etc.

The previous example of the “123456789” text and the update thereof tothe updated version “123756489”, wherein each segment includes logicallysequential content and performs uniform behavior during update, is asimplified example. In other examples it is possible to divide thecontent into segments that are logically sequential, perform uniformbehavior during update and occupy physically sequential area in one ormore physical block. Thus, if “123” is fragmented in a way where “12” isstored in a first block, while “3” is stored in a second block, wherein“12” does not sequentially precede “3”, then according to this example“123”, although logically sequential, should be divided into twosegments (specifically there are “12” and “3”).

In this latter example the segment “12” can yet reside on two differentblocks, as long as the blocks are sequential (a first block sequentiallyprecedes a second block) and as long as the character ‘1’ is stored inan area ending the first block while the character ‘2’ is stored in thearea opening the second block.

This latter example is non-binding. For example, an alternativeembodiment can limit a segment to occupy physically sequential area inone physical block (unlike “one or more” in the previous example). Thus,if “12” is sequentially stored in two sequential blocks it must befurther divided into two segments (one is “1” and the second is “2”).

When content of a segment in the updated version (an “updated segment”)corresponds to content of a segment in the original version (an“original segment”), these segments are considered as “correspondingsegments” or “matched segments”. Correspondence refers to any logicalconnection between the segments, wherein the updated segment can be acopy of the original segment, it can be a modified copy of the originalsegment (e.g., in large segments it is sometimes preferred to copy awhole segment and then modify part of the copied content), or it caninclude content received by performing a calculation using contentstored in the original segment etc.

It is noted that sometimes there may be more than one updated segmentcorresponding to a certain original segment (e.g., the content of theoriginal segment is copied twice, thus generating two updated segmentscorresponding thereto). The opposite is also true: Sometimes there maybe more than one original segment corresponding to a single updatedsegment (e.g., in order to calculate the content of a single updatedsegment, it is possible to use content stored in two distinct originalsegments).

It was previously mentioned that in order to update an original versionto an updated version, an update process operate in accordance with anupdate package. According to one embodiment, the update package includesupdate commands (shortly “commands”), wherein each command correspondsto one segment in the original and/or updated versions. An updatecommand can include a code indicative of an update operation and it isappreciated that the codes can be, e.g., a numerical code, bit-mask, astring code or any other code applicable to the case.

There are different update operations and hence update commands that areallowed for updating an original version to an updated version. Forexample:

-   -   A “delete” command corresponds to one segment in the original        version, whose content is deleted when generating the updated        version (hence this command does not correspond to any segment        in the updated version). A deleted segment in the original        version has no corresponding segment in the updated version. The        delete command frees the segment in the storage device thus        allowing writing other content into the segment. That is, the        update process does not need to physically delete the content.        It can only mark this area as free.    -   An “insert” command corresponds to one segment in the update        version, wherein new content is added into this segment. An        inserted segment in the updated version has no corresponding        segment in the original version. It is noted that in some        embodiments, when inserted content is written in a non-free area        (i.e., physical area that includes content that was not freed        before, for example, by a delete command), the original content        is overridden by the inserted content and therefore considered        as deleted. In these embodiments such an insert command is        considered as equivalent to a delete command followed by an        insert command.    -   A “copy” command corresponds to one segment in the original        version (an “original segment”) and to one segment in the        updated version (an “updated segment”), wherein content of the        original segment is copied to the updated segment. The original        and updated segments are considered as corresponding segments.        After performing a copy operation (in accordance with a copy        command), the area previously occupied by the original segment        is considered free, thus it is allowed to write other content        therein. It is noted that the update process does not need to        physically delete (free) the content. It can only mark this area        as free. In addition, similarly to the insert command, there are        some embodiments, wherein inserted content that is written into        a non-free area (i.e., physical area that includes content that        was not freed before, for example, by a delete command),        overrides the non-freed content, which is therefore considered        as deleted. In these embodiments such a copy command is        considered as equivalent to a delete command followed by a copy        command.    -   A “replace” command replaces content of an original segment with        new content in the update version and hence it corresponds to        one original segment and to one updated segment. The content of        the original segment is deleted while supplementary data (such        as data stored in the replacements supplementary data portion,        419, of FIG. 4 below) is written into the updated segment.        However, those versed in the art would appreciate that there are        transforming functions, such as bitwise XOR (exclusive or), that        transform data to another in a reversible manner. For example,        it is possible to bitwise XOR the content of the original        segment with data (“transforming data”) that yields the content        of the updated segment. Those versed in the art would appreciate        that it is later possible to bitwise XOR the updated content        with the transforming data to yield back the original content        (bitwise XOR is a mathematically revertible function, i.e. if “A        XOR B=C” than “C XOR B=A”). In an embodiment using transforming        functions to replace content the supplementary data can include        the transforming data.

It is noted that the exemplary commands described above are non-limitingand there may be additional types of update commands (such as “backup”)or fewer types of update commands in an update package. For example, itshould be appreciated that instead of a “replace” command it is possibleto use a combination of “delete” and “insert” as was previouslyexplained. According to a different example there can exist a simpleupdate package that instructs the update process only to delete onesegment (and hence this package does not include any insert, copy andreplace commands), etc.

There are storage devices 103 that permit accessing content (for readingand/or for writing) stored in one block at a time. In an update packageadapted for such a storage device, the commands corresponding to asingle block should better be organized in groups, wherein the commandsin each group correspond to one block and do not include commandscorresponding to other blocks interweaved in between. Doing this theupdate process can access in one read operation all the original contentthat is required from the original block or access in one writeoperation all the updated content that is required to the updated block.Interweaving commands that correspond to different blocks in an updatepackage adapted to such a storage device, whenever the update processperforms an operation in accordance with a command it accesses the wholeblock, although it actually requires access to a segment thereof.

Before turning to FIG. 2, it is noted that the term “stored version” isused for referring to the version currently stored in the storagedevice. The stored version can be, e.g., an original version, it can bean intermediate version, as illustrated, for example, with reference toFIG. 2 below, or it can be an updated version.

FIG. 2 illustrates simplified exemplary stages in updating an originalversion 201 to an updated version 202 in a storage device allowingaccess to whole blocks. The original version 201 includes four blocks,specifically these are 203, 204, 205 and 206. The updated version 202,according to this example, also includes four blocks, namely 207, 208,209 and 210, wherein block 207 replaces block 203, block 208 replacesblock 204, block 209 replaces block 205 and block 210 replaces block206. According to the example, the update process first replaces block203 with block 207. Thus, the stored version 211 includes a combinationof the original version 201 and the updated version 202, wherein thefirst block is 207 (which belongs to the updated version) while theother blocks (i.e., 204, 205 and 206) still belong to the originalversion 201. Next, according to the example, the update process replacesblock 204 with block 208, thus the stored version becomes 212. Then thestored version 213 is generated, and finally the stored version becomesthe updated version 202. Versions that are partly original and partlyupdated (e.g., versions 211, 212, 213) are referred to as “intermediateversions”.

It should be appreciated that the update process illustrated in FIG. 2can terminate, normally or not, at any stage. Thus, the stored versionstored in the storage device can be any of the versions 201, 211, 212,213 or 202. Furthermore, since interruption may occur while storingcontent in an updated block, the last updated block at the point ofinterruption may be corrupted, that is, it may contain undefined contentas is known to those versed in the art.

It should be noted that the example provided with reference to FIG. 2 isby no way binding. Original, intermediate and/or updated versions caninclude any number of blocks, a block can include any applicable numberof bits and the update process can perform any operation applicable tothe case apart or in addition to replacing blocks (such as deletingblocks, inserting blocks, moving blocks etc.).

In addition, in a storage device that allows access to portions ofblocks, there can also exist original, updated and intermediateversions. However, in these cases FIG. 2 would illustrate segmentsinstead of blocks.

FIG. 3 illustrates an exemplary original version 301 and a correspondingexemplary updated version 302. The original version is sometimes alsoreferred to as a “source version” while the updated version is sometimesreferred to as a “target version”. Segments 303, 304, 305, 306, 307 and308 constitute together the original version 301, while segments 309,310, 311, 312, 313, 314 and 315 constitute together the updated version302. It is noted that the original version includes fewer segmentscompared to the updated version (six segments in the original versioncompared to seven segments in the updated version). Thus, the updateprocess inserted new content (segments 311 and 313 in the example) intothe updated version. In addition, it is noted that the content ofsegments 303, 305, 306 and 308 in the original version is identical tothe content of segments 309, 312, 315 and 314 of the updated version,respectively. That is, the original content of these segments is copiedinto the corresponding segments in the updated version. Furthermore, thecontent of segment 307 of the original version is deleted thus it doesnot appear in the new version, while the updated content of segment 310replaces the original content of segment 304.

In the example of FIG. 3 the original version 301 is stored in one blockin the storage device, specifically, block 316. The update process is anin-place update process, that is, the updated version overrides theoriginal version, hence the update version 302 is also stored in block316. However, this is non-limiting and a version (an original and/orupdated version) can be stored in more than one block as was previouslyexplained, with reference to the “123456789” example. In addition, it ispossible to see 301 and 302 as part of larger original and updatedversions. Thus, the term “original version 301” and “updated version302” refer to the versions as a whole, or to one block there from.

While looking at the figure it is illustrated that there are two freesegments padding the original version 301 on both sides. Specifically,these are segments 318 and 319. There are also two free segments, 320and 321 padding the updated version 302. It is noted that the freesegments 318, 319, 320 and 321 are not part of the original or updatedversions, instead they are unused spaces in the block 316, when occupiedby the original or updated version. These free segments can sometimes beused for storing content which is part of other files. It is furthernoted that according to the example, the free segment 320 is smallerthan the free segment 318, while the free segment 321 is smaller thanthe free segment 319. That is, the space occupied by the originalversion 301 is smaller than the size occupied by the updated version302.

The segments 303 and 309 are corresponding segments. Similarly are 304and 310; 305 and 312; 306 and 315; and 308 and 314.

FIG. 4 illustrates alternative update packages 401 and 402 adapted toupdate the original version 301 of FIG. 3 to the updated version 302thereof. The update package 401 includes update commands for updatingthe version. The command 403 instructs the update process to copy theoriginal content of segment 303 to the updated segment 309. The updatecommand 404 instructs the update process to replace the original contentof segment 304 with the “replaced data”, thus yielding the updatedcontent of the updated segment 310. It should be noted that it is alsopossible to use a transforming function, such as XOR in order to replacedata, as was previously explained. In such an embodiment the “replaceddata” would store the transforming data.

Command 405 is in charge for deleting the original content of segment307; command 306 copies the original content of segment 308 to theupdated segment 314; command 407 copies the original content of segment306 to the updated segment 315; command 408 instructs the update processto insert the “inserted data” into the updated segment 313; command 409instructs it to copy the original content of segment 305 to the updatedsegment 312; and command 410 is in charge of inserting the inserted dataas the updated content of segment 311. It is noted that data provided tothe update process, such as inserted and/or replaced data, areinterweaved with the update commands of the update package 401. Such anupdate package, where data are interweaved with the update command isreferred to as a “data indistinct update package” or “data interweavedupdate package”.

It is noted that the order by which the update commands appear in theupdate package is not necessarily equivalent to the order of therespective segments in the original and/or updated versions. Inaddition, it is noted that if 301 and 302 are parts of an original anupdated version then the update package includes additional commands,for updating additional segments of additional blocks. In this case 401is part of an update package.

It is further noted that data such as “inserted data” and “replaceddata” that are required for some update commands are generallyreferenced as “supplementary data”. An update command that requiressupplementary data is referenced as a “data consuming update command”.

The update package 402 is an alternative update package (or a partthereof) that generates the updated version 302 from the originalversion 301. The update commands in the update package 402 areequivalent to the update commands of the update package 401, and orderedin the same order as they appear therein: command 411 is equivalent tocommand 403; command 412 is equivalent to command 404; command 413 isequivalent to command 405; command 414 is equivalent to command 406;command 415 is equivalent to command 407; command 416 is equivalent tocommand 408; command 417 is equivalent to command 409; and command 418is equivalent to command 409. However, in the update package 402, unlikethe update package 401, all the supplementary data required for insertand replace commands appear in the end of the update package. Theportion 419 of the update package is used for storing supplementary datarequired for replace commands (hence it is referred to as a“replacements supplementary data portion”), while the portion 420 of theupdate package is used for storing data required for insert commands(hence it is referred to as an “insertions supplementary data portion”).Such an update package, where supplementary data are stored insupplementary data portions is referred to as a “data distinct updatepackage”.

It is noted that each supplementary data portion (such as portions 419and 420) can include supplementary data items that correspond to morethan one data consuming update command. In the example of FIG. 4, theinsertions supplementary data portion 420 includes supplementary data ofthe update commands 416 and 418.

According to one embodiment, a data consuming update command can includea pointer to the respective supplementary data item that is stored inthe update package, e.g., a pointer to the beginning of supplementarydata item included in one of the portions 419 and 420. According to adifferent embodiment, each update command that requires supplementarydata can include the size of the respective data, thus allows computingthe position where the respective supplementary data item begins. Thisis non-binding and other embodiments are allowed as well. For example,the supplementary data portion can associate with each supplementarydata item the size of this item. If the supplementary data items arestored in the supplementary data portion by the same order of the dataconsuming update commands in the update package, then a person versed inthe art would appreciate that this embodiment allows computing theposition where a supplementary data item, respective of each dataconsuming update command begins.

It would be appreciated by those versed in the art that originalversions are updated to yield updated versions. Such an update (of anoriginal version to an updated version) is referenced as “forwardupdating”. In addition, those versed in the art would appreciate thatwhile forwarded updating versions, an update package is processed fromits beginning towards its end. Processing an update package from itsbeginning towards its end is referred to as “forward processing” of theupdate package.

According to the invention, it is sometimes required to reverse thedirection of update, thus returning to the original version. Such areverse is sometimes desired, for example, when the forward updateprocess fails in the middle, thus yielding a stored version that is anintermediate version. A cellular operator, for example, may wish toreturn to the previous version (the original version) when such failureoccurs.

According to another example, when an update process starts operating itcan present a message to the user such as “the handheld is now updatingsoftware. The update is expected to last for 30 minutes during which thetelephone will be inoperable”. If the user must use his telephone withinthe coming 30 minutes he is given the option to cancel the updateprocess (thus postponing it to some later time). However, the updateprocess can perform part of the update task before the user pressescancel, which results in an intermediate version. Therefore, when theuser presses “cancel” the update process has to reverse and return tothe original version.

Returning from a stored version to its corresponding original version isreferred to as “roll-back”, while an update process that performsroll-back is referred to as a “rolling-back update process”. Accordingto one embodiment of the invention a rolling back update process canoperate in accordance with the update package used for forward updatingthis original version, but in a reversed direction (i.e., from its endtoward the beginning) as will further be explained in detail.

The examples provided are by no way limiting and other examples andreasons for roll-back exist as well. One such additional example is whena cellular operator successfully updates an original version to anupdated version, however, the updated version is found non-satisfactoryand therefore the operator would rather return (roll-back) to thepreviously operating original version. That is, roll-back does notrequire that the stored version would be an intermediate version; it canoccur also when the stored version is an updated version.

Returning to the update package 402 of FIG. 4, 421 is a “directionindication”, constituting “update attribute bits”. The directionindication is used to indicate the direction by which the update processshould operate, and/or the reason for this operation. For example, therecan be different codes for the different directions and/or reasons ofoperation.

However, this is non-limiting and other embodiments can store thedirection indication in other storage areas which are not necessarilypart of the update package. For example, there can be a “directionindication buffer” in the storage device 103.

In accordance with certain embodiments the direction of the update isone of two directions. Specifically, the direction is one of forward androll-back. This is non-limiting and other embodiments can have anydirection applicable to the case.

When an update process, operating in accordance with one embodiment ofthe invention starts operating, it needs to identify the direction ofoperation and the start position. It is noted that when a forward updateinitially begins, the stored version is normally the original version,the start position is the beginning of the original version and thebeginning of the update package, and the direction is forward (as wasalready noted). However, if the stored version is an intermediateversion, the start position would be somewhere along the intermediateversion and along the update package. Similarly, the direction can beeither forward or roll-back.

Returning to FIG. 3, it was already mentioned that during the updateprocess several segments were modified (therefore constituting “replacedblocks” or “inserted blocks”). It was also explained with reference toFIG. 4 that the content of the modified segments is provided with theupdate package used by the update process. Thus, it is possible topredict what should be the content of an updated segment, based on theupdate package.

According to one embodiment, therefore, it is possible to include in theupdate package signatures corresponding to the modified portions in theupdate segments. A signature, for example, can be a known per sechecksum computed for the specific block. The signatures can be storedtogether with their corresponding blocks. However, alternativeembodiments are allowed as well, such as storing signatures in thebeginning or end of the update package, in separated tables etc.

It was also explained (e.g., with reference to FIGS. 3 and 4) thatcontent of some segments is copied from the original version to theupdated version. Therefore, given an original version and an updatepackage, it is possible to compute signatures for all segments in theupdated version. Furthermore, it is possible to compute one signaturethat corresponds to all the segments in a block that are part of theupdated version. Such a signature is referred to as a “block's updatedsignature”.

It is further possible, according to the embodiment, to calculate a“block's original signature”, that is, a signature that corresponds toall the segments in a block that are part of the original version.

Understanding this, and bearing in mind the explanation that a storedversion can be either an original version, an intermediate version or anupdated version (see, for example, FIG. 2), a person versed in the artwould appreciate that by calculating signatures of blocks in the storedversion and comparing them with the blocks' original signatures and withthe blocks' updated signatures it is possible to determine the identityof the stored version. Furthermore, if the stored version is determinedto be an intermediate version, it is possible to determine the positionof interruption of the previously running update process. Then it ispossible to locate the update command in the update package thatcorresponds to the position of interruption.

In storage devices that allow access to content that occupies part of ablock it is further possible to compare segments' signatures, in orderto determine the segment where interruption of the previously runningupdate process occurred.

It is further possible to associate with the update package recordsreferenced as “state records”. According to one embodiment it ispossible to associate a state record with commands corresponding to eachblock, wherein the state record reflects the state of the updateprocess, as it should be after the update of the corresponding block iscompleted. For example, the state-record can include a copy of the blockin RAM used by the update process to hold variables that maintain theprocess, such as known per se local variables.

After determining the identity of the stored version, the position ofinterruption of the previously running update process and the staterecord, it is possible, according to one embodiment of the invention, toreverse (or revert) the update process, thus returning to the originalversion that existed before the previously running update processstarted running.

FIG. 5 is a flowchart illustrating operations performed before reversingan update process, according to an embodiment of the invention. In 501the update sequence is determined in accordance with the update packageand in 502 the update process reads the first block of the storedversion in accordance with the update sequence. In 503 the signaturecorresponding to the read block is accessed (e.g., by reading it fromthe update package) and a corresponding signature is calculated in 504,based on content read in 502. If in 505 the update process identifiesthat the two signatures match and as long as there are other,un-examined blocks (see 506), the signature corresponding to the nextblock in accordance with the update sequence is accessed in 507 and in508 the block is read in order to calculate its corresponding signaturein 504. If in 506 it is found that there are no more un-examined blocks,this means that the stored version is an updated version and the updateprocess terminates without reversing. It is noted though that this isnon-limiting and other embodiments can reverse even a stored version,which is an updated version.

When in 505 the two signatures do not match, the update process canaccess the state record that corresponds to the read block, as done in509, in order to restore the process state in 510. Once the state hasbeen restored, the process reverses in 511 in order to return to theoriginal version.

It is noted that according to one example, while updating a block theupdate process stores its original content in a backup buffer to allowrestoring its content if the update process fails before the block'supdate is complete (‘backup-first’). A different example can store theupdated block's content in the backup buffer (‘update-first’) withoutincurring changes to the block itself, instead of the original content,and then copy the updated content from the backup buffer to the block.In the backup-first case, when locating the point of interruption it ispossible that the content of this block is corrupted. In this case thecontent can be recovered from the backup buffer. Alternatively, in caseof ‘update-first’, the new content already exists in the backup buffer.

It is noted that FIG. 5 is non-binding. In an alternative embodiment thesignatures in the update package can correspond to blocks in theoriginal version instead of the updated version. Those versed in the artwill appreciate that instead of comparing signatures locating the pointof interruption by looking to the first block in the stored versionwhose signature does not match to the corresponding signature in theupdate package, in this alternative embodiment it is required to lookfor the first block in the stored version whose signature does match tothe corresponding signature in the update package, wherein the point ofinterruption is the previous block in the stored version, according tothe update sequence.

It was previously described that roll-back is sometimes performed due touser (hand-held owner) selection etc. In case of owner's initiatedroll-back, it is not necessarily required to search for the startposition. According to one embodiment of the invention, when cancelingan update process it is possible to store an indication of the startposition (the indication can be stored, for example, in association withthe direction indication).

Before turning on to describe how reversal can be performed, it is notedthat it is also possible to reverse a rolling-back update, thus yieldinga forward update. For example, if an owner cancels a forward update(thus starting a roll-back), he can change his mind and reverse theupdate process again (by canceling the rolling-back update process),thus returning to the forward update, which results with an updatedversion. That is, according to one embodiment, when canceling an updateprocess it is possible to “toggle” between forward and roll-backdirection indications.

It is noted that because the term ‘reversal’ explains reversal fromforward updating to rolling-back and vice versa the update processoperating before the reversal is referred to as pre-reversal updateprocess and the one operating after the reversal is referred to aspost-reversal update process. It should be understood that if thepre-reversal update process performs forward update, then thepost-reversal update process performs roll-back. The contrary is alsocorrect: if the pre-reversal update process performs roll-back, then thepost-reversal update process performs forward update.

Similarly, the stored version that exists before the update process(forward-update or roll-back) starts operating is generally referred toas source version, while the stored version that the update process isgenerally referred to as a “target version”. The source version can bean original version, an updated version or an intermediate version. Thetarget version can be either an original version or an updated version.

According to one embodiment of the invention, in order to allow reversal(from forward updating to rolling-back and vice versa), it is requiredto backup any content deleted during the pre-reversal update process, asit will be necessary to re-introduce this content into the targetversion. FIG. 6 illustrates by way of example storing deleted contentduring a pre-reversal update process, according to one embodiment of theinvention. In the figure, there is illustrated one segment 307 of theoriginal version 301 (see FIG. 3), which is the source version in thisexample. There is also illustrated a portion of the update package 402of FIG. 4, wherein the illustrated portion includes the delete updatecommand 413, in charge for deleting segment 307. The portion alsoincludes the replacements supplementary data portion 419, the insertionssupplementary data portion 420 and the direction indication 421.

In addition, a “content reserve buffer” 601 is illustrated. The contentreserve buffer, constituting a “save buffer”, is an area in the storagedevice 103 accessible to the update process, that is specially allocatedin order to allow reserving deleted content. According to one embodimentthe content reserve buffer 601 can be allocated temporarily only for theduration of the update process and be reused afterwards for any othertask. Before deleting content during the update process, it is possibleto reserve (602) a copy thereof in the content reserve buffer.Alternatively, it is possible to dedicate space in the update packagefor the content reserve buffer, thus ensuring that there is enough spacein the storage device 103 for this buffer, in the cost of a largerupdate package (which requires more bandwidth and/or more time totransmit, compared to a smaller update package).

It is noted that FIG. 6 illustrates reserving content during a deleteoperation. However, this is non-limiting and according to someembodiments reserving should occur whenever the update process performsan operation that overrides content, such as “replace”, in order toallow for a later reversal of the advancing update process. It isfurther noted that embodiments operating a transforming function whileperforming a “replace” operation, can avoid reserving the stored contentbefore overriding it with the replacing content, because thetransforming data can be re-applied to the replacing content in order tore-transform it back to content identical to the stored content.

The embodiment of FIG. 6 is non-binding and alternative embodiments areallowed as well. For example, it is possible to include a copy of thedeleted data in the update package. This way more network resources willbe required in order to transmit the update package (which becomes evenlarger), yet, the update process will be faster, as no reserveoperations are required.

FIG. 7 illustrates by way of example reducing usage of a content reservebuffer, according to one embodiment of the invention. It is noted thatsupplementary data items used for insertion and replacement commands inthe pre-reversal update process are not required after performing theirrespective update commands as their supplementary data is alreadywritten into the target version. Yet, it was already explained thatcontent deleted during the advancing update process is reserved, e.g.,in the content reserve buffer. Thus, it is appreciated that the contentstored in the content reserve buffer can be copied (701) into the updatepackage, in-place of the already used supplementary data 420, allowingto free (and/or re-use) the content reserve buffer thereby.

As suggested by the latter example of FIG. 7, the update package itselfcan be updated in-place, which may require a reliable modificationmethod for modifying its storage area in case the update process isinterrupted. Reliable in-place modification of the update package canuse any reliability technique, such as using a backup buffer, packagesignatures and state records as was previously explained.

According to one embodiment of the invention it is possible to replacethe supplementary data items whenever they become “free” (i.e.,substantially immediately after using each one of them). According to adifferent embodiment it is possible to replace the supplementary dataitems at a later time, e.g., upon termination of the update process.

It should be appreciated that sometimes there are two or more deletedsegments, whose content (or al least part of their content) is similaror shared. According to an alternative embodiment, when two or moresegments share content, this content can be reserved only once, whilethe other occurrences can reserve an indication as to where the reservedcontent is stored or how to retrieve it.

When the pre-reversal update process terminates, the directionindication 421 is set to indicate which direction should a precedingupdate process operate, if such an update process initiates. It is notedthat if the pre-reversal update process fails, or stopped in the middle,it also sets the direction indication 421, to indicate whether thepreceding update process (if initiated) should operate in a forward orroll-back mode (such as in FIG. 5, 511).

According to the invention, reversing a forward update process isperformed by undoing each of the update commands performed by theforward update process but in a reversed order, starting from the lastupdate command performed by the forward update process, and terminatingwith the first update command in the update package. Similarly,reversing a rolling-back update process is performed by redoing each ofthe update commands, whose reversing command was performed by therolling-back update process, starting from the last reversed-updatecommand performed by the rolling-back update sequence.

Reversing will be further explained with reference to the examplepreviously presented in FIGS. 3 and 4. According to the example it isassumed that the forward update process operated successfully andyielded the updated version 302 by updating the original version 301 inaccordance with the update package 402. It is noted that following thissuccessful forward update the direction indicator 421 indicates that theupdate process direction should be reversed (i.e., the preceding updateprocess, if initiated, will operate as roll-back).

According to the example, the rolling-back update process undoes theupdate operations done by its preceding forward update process, but in areversed order: starting from the last update command executed beforethe advancing process terminated and terminating with the first updatecommand 411. In the is example, the first update command to be undone byduring roll-back is 418. It is noted that while reversing an updateprocess, the supplementary data portions (420 and 421 in the figure) arealso accessed in a reversed order.

According to the example, the supplementary data portions includereserved content written thereto while deleting content during theforward update. Understanding that a rolling-back update behaves like aforward update (apart from the reversed direction of progress and thereversal of the commands), it should be appreciated that whenever therolling-back update process deletes content from the stored version, acopy of the deleted content is written into the supplementary dataportions (or into the content reserve buffer).

The following example explains how each of the exemplary update commands(copy, delete, insert and replace) can be undone by performing anappropriate operation (a “reversing update command” or “revertingoperation”), which reverses the original operation's result:

-   -   A “delete” operation can be undone (or rolled-back, reversed) by        an insert operation. The content previously deleted by the        delete command is the supplementary data for the insertion        command. For example, the delete operation performed by the        command delete 307 (see, for example, command 413) is reversed        by insert 307 supplementary-data (wherein the supplementary data        can be store in the supplementary data portion or in the content        reserve buffer).    -   An “insert” operation performed in accordance with an “insert”        command can be undone by a delete operation. For example,        command 418 (insert 311) can be undone by performing delete 311.        It is noted that when deleting content while performing the        reversing command, the deleted content should be reserved, e.g.        in the content reserve buffer or in the insert supplementary        data portion.    -   A “copy” operation can be undone by copying the updated segment        back to its original position. For example, the command 417        (copy 305→312) can be reversed by the command copy 312→305.    -   A “replace” operation can be undone by deleting content inserted        by the pre-reversal update process and writing instead data        stored in the replacements supplementary data portion 419 or in        the content reserve buffer. In other words, a replace operation        can be undone by another, reversed, replace operation. However,        those versed in the art would appreciate that if a transforming        function such as bitwise XOR is used for ‘insert’ in the        pre-reversal update process, then the insert operation can be        reversed by operating the same transforming function on the        content previously written by the pre-reversal insert operation        using the supplementary data (transforming data), in order to        yield back the content stored in the pre-reversal segment.

It is thus illustrated that a reversed update command (or a rolling-backupdate command) reversely corresponds to an update command.

FIG. 8 is a flowchart illustrating the main procedures performed whileupdating a source version to a target version in a reversible updateprocess, according to one embodiment of the invention. It is noted thatthe direction of the update process is determined in 801 in accordancewith the value of the direction indicator 419. If the indicatorindicates that the update process should operate as forward update, thenthe update process will operate in 802 in accordance with the updatepackage in a forward direction. Upon termination (normal termination orfailure), in 803, the update process will set the direction indicator toindicate that a preceding update process, if initiated, should performroll-back. However, if the update process determines in 801 that theupdate process should operate to perform roll-back, then it will operatein 804 in accordance with the update package in roll-back direction.Upon termination (normal termination or failure), in 805, the updateprocess will set the direction indicator to indicate that a precedingupdate process, if initiated, should perform forward-update.

FIG. 9 is a flowchart illustrating in detail a forward update process,according to one embodiment of the invention. Upon start, in 901, theupdate process has to locate the position in the stored version where itshould start updating. It is appreciated that if the stored version isthe original version then the start position is the beginning of theversion, if the stored version is the updated version then the startposition is the end of the version (hence the forward update processwill terminate without performing any update operation), and if thestored version is an intermediate version then the start position is inthe termination point of the previously running update process (see, forexample, FIG. 5).

In 902 the update process initiates the process state. If the storedversion is an intermediate version then the state would be initiated inaccordance with the state record. However, if the stored version is anoriginal or updated version then the state would be initiated as new. Inaddition, at this stage the update process locates the update commandfrom where it should start reading, and it determines pointer positionssuch as in the replacements supplementary data portion 419, theinsertions supplementary data portion 420 and the content reserve buffer601, thus allowing it to access (for reading and/or writing) the correctdata items stored therein.

It is illustrated in 903 that if the stored version is an updatedversion, and remembering that the update process is a forward updateprocess, then there are no more update commands in accordance with theupdate sequence, and therefore the update process terminates withoutperforming any update command. However, if the stored version is anoriginal version or an intermediate version then the update processreads from the update package the next update command in accordance withthe update sequence and operates accordingly. If the update command is a‘copy’ command (905) the content of the original segment is copied intothe updated segment in 906. It is noted that when the target segment isnot free, there are some embodiments that require reserving the contentstored therein in the content reserve buffer (or in the insertionssupplementary data portion 420), as if there is a delete command beforethe copy command.

If the command is an ‘insert’ command (907) then in 908 data is copiedfrom the insertions supplementary data portion 420 into the updatedsegment and in 909 the pointer in the insertions supplementary dataportion is advanced to the next data item. Again, there may be someembodiments wherein before inserting the supplementary data into theupdated segment, if the updated segment is not free, content storedtherein is reserved in the content reserve buffer (or in the insertionssupplementary data portion 420), as if there is a delete command beforethe copy command.

If the command is a ‘delete’ command (910) then in 911 the contentstored in the original segment is copied into the content reserve buffer(or into the insertions supplementary data portion 420), and in 912 thepointer to in the content reserve buffer is advanced to the nextavailable space.

According to the example (where there are ‘copy’, ‘insert’, ‘delete’ and‘replace’ commands), those versed in the art would appreciate that ifthe update command is neither ‘copy’, nor ‘insert’ nor ‘delete’, it mustbe ‘replace’. Therefore, in 913 the content of the original segment isbitwise XORed with the transforming data, wherein the result is storedin the updated segment (see 914) and the pointer to the next data itemin the replacements supplementary data portion 419 is advanced to thenext data item.

FIG. 10 is a flowchart illustrating in detail rolling-back a storedversion, according to one embodiment of the invention. Upon start, in1001, the update process has to locate the position in the storedversion where it should start updating. It is appreciated that if thestored version is the original version then the start position is thebeginning of the version (hence the rolling-back update process willterminate without performing any update operation), if the storedversion is the updated version then the start position is the end of theversion, and if the stored version is an intermediate version then thestart position is in the termination point of the previously runningupdate process (see, for example, FIG. 5).

In 1002 the update process initiates the process' state. If the storedversion is an intermediate version then the state would be initiated inaccordance with the state record. However, if the stored version is anoriginal or updated version then the state would be initiated as new. Inaddition, at this stage the update process locates the update commandfrom where it should start reading, and it determines pointer positionssuch as in the replacements supplementary data portion 419, theinsertions supplementary data portion 420 and the content reserve buffer601, thus allowing it to access (for reading and/or writing) the correctdata items stored therein.

The rolling-back update process operates in accordance with a roll-backupdate sequence, which is opposite to the update sequence of the updatepackage. It is illustrated in 1003 that if the stored version is anoriginal version, and remembering that the update process is arolling-back update process, then there are no more update commands inaccordance with the roll-back update sequence, and therefore the updateprocess terminates without performing any update command. However, ifthe stored version is an updated version or an intermediate version thenthe roll-back update process reads from the update package the nextupdate command in accordance with the reversed update sequence (or inother words: the previous update command in accordance with the updatesequence) and performs the update operation reversely corresponding tothe update command.

If the update command is a ‘copy’ command (1005) the content of theupdated segment is copied into the original segment in 1006, which isthe update command reversely corresponding to the ‘insert’ command. Itis noted that when the original segment is not free, there are someembodiments that require reserving the content stored therein in thecontent reserve buffer (or in the insertions supplementary data portion420), as if there is a delete command before the copy command, inaccordance with the roll-back update sequence).

If the command is an ‘insert’ command (1007) then in 1008 data is copiedfrom the stored version to the content reserve buffer (or to theinsertions supplementary data portion 420), which is the update commandreversely corresponding to the ‘insert’ command, and in 1009 the pointerto the content reserve buffer is advanced to the next available space(alternatively the pointer to the insertions supplementary data portionis retreated to the previous data item).

If the command is a ‘delete’ command (1010) then in 1011 data is copiedfrom the insertions supplementary data portion 420 (or from the contentreserve buffer) into the original segment, and in 1012 the pointer inthe insertions supplementary data portion is retreated to the previousdata item. Again, there may be some embodiments wherein before copyingthe supplementary data into the original segment, if the originalsegment is not free, content stored therein is reserved in the contentreserve buffer (or in the insertions supplementary data portion 420), asif there is an insert command before the delete command, in accordancewith the roll-back update sequence).

According to the example (where there are ‘copy’, ‘insert’, ‘delete’ and‘replace’ commands), those versed in the art would appreciate that ifthe update command is neither ‘copy’, nor ‘insert’ nor ‘delete’, it mustbe ‘replace’. Therefore, in 1013 the content of the updated segment isbitwise XORed with the transforming data, wherein the result is storedin the original segment (see 1014). According to the embodiment thetransforming data is stored in the replacements supplementary dataportion 419. Therefore, in 1015 the pointer to the next data item in thereplacements supplementary data portion 419 is retreated to the previousdata item.

The invention provides for a method for providing an update process of astored version. The method comprising:

providing a forward update for updating the stored version to a firstversion;

providing a roll-back update for updating the stored version to a secondversion;

applying a first update operation being either of said forward updateand said roll-back update; and

applying a second update operation being either of said forward updateand said roll-back update and being other than said first updateoperations.

It is appreciated that in accordance with certain embodiments the firstversion can be one of several versions, including original version andupdated version. However, this is non-limiting and other embodiments mayhave a different version being the first version, such as anintermediate version.

Similarly, it is appreciated that in accordance with certain embodimentsthe second version can be one of several versions, including originalversion and updated version. However, this is also non-limiting andother embodiments may have a different version being the second version,such as an intermediate version.

In addition, it is appreciated that in accordance with certainembodiments the first update operation can be one of several updateoperations, such as forward update operation and roll-back updateoperation. This is non-limiting and other embodiments may have differentupdate operation being the first update operation.

It is also appreciated that in accordance with certain embodiments thesecond update operation can be one of several update operations, such asforward update operation and roll-back update operation. This isnon-limiting and other embodiments may have different update operationbeing the second update operation.

FIG. 11 is a block diagram schematically illustrating a system 1101 forupdating a stored version of content stored in a storage device,according to one embodiment of the invention. The system 1101 includes adirection determination unit 1102 adapted for determining direction ofthe updating, for example, in accordance with the direction indication421.

The system 1101 also includes a forward updating processor 1103 coupledto the direction determination unit 1102. When the directiondetermination unit 1102 determines that the direction of the updating isindicative of forward, the forward updating processor 1103forward-updates the stored version to the updated version in accordancewith the update sequence. This is done, for example, in accordance withthe flowchart of FIG. 9.

When the direction determination unit 1102 determines that the directionof the updating is indicative of roll-back, a roll-back sequencegenerator 1104 that is coupled to the direction determination unit 1102generates a roll-back update sequence opposite to the update sequence.The roll-back sequence generator 1104 can follow the update sequence ina reversed order, one command at a time. Alternatively it can follow theupdate sequence altogether, thus generating and storing the roll-backupdate sequence in the storage device, e.g., as a list.

The system 1101 also includes a roll-back updating processor 1105coupled to the roll-back sequence generator 1104. The roll-back updatingprocessor 1105 rolls-back the stored version to the original version inaccordance with the roll-back update. This is done, for example, inaccordance with the flowchart of FIG. 10.

FIG. 12 is block diagram schematically illustrating a system forreversing an update process, according to one embodiment of theinvention. The system 1201 includes an update commands reversal unit1202. The update commands reversal unit 1202 reverses update commands inthe update package that were previously performed during updating. See,for example, 1006, 1008, 1011 and 1013 in FIG. 10.

FIG. 13 is a block diagram schematically illustrating a system 1301 forupdating a stored version of content stored in a storage device. Thesystem 1301 includes a direction determination unit 1302. According toone embodiment, the direction determination unit 1302 uses the directionindication in order to determine direction.

A forward updating processor 1303 is coupled to the directiondetermination unit 1302. When the direction is indicative of forward,the forward updating processor 1303 forward-updates the stored versionto the updated version, e.g., in accordance with the flowchart of FIG.9.

The system 1301 also includes a roll-back update processor 1304. Whenthe direction determination unit 1302 determines that the direction isroll-back, the roll-back update processor 1304 rolls-back the storedversion to the original version, e.g., in accordance with the flowchartof FIG. 10.

It will also be understood that the system according to the inventionmay be a suitably programmed computer. Likewise, the inventioncontemplates a computer program being readable by a computer forexecuting the method of the invention. The invention furthercontemplates a machine-readable memory tangibly embodying a program ofinstructions executable by the machine for executing the method of theinvention.

The present invention has been described with a certain degree ofparticularity, but those versed in the art will readily appreciate thatvarious alterations and modifications may be carried out, withoutdeparting from the scope of the following Claims:

1. A method of in-place updating a stored version of content stored on astorage device using an update package that is adapted to update anoriginal version of content to an updated version and that includesupdate commands in a particular order, the method comprising:determining a direction of the in-place updating; and in-place updatingthe stored version in accordance with the determined direction, whereinwhen the determined direction is forward, then in-place updatingincludes: forward-updating the stored version to the updated version, inaccordance with the update commands included in said update package,according to the particular order; reserving content which has beendeleted during the in-place updating; and storing the reserved contentin segments of physical blocks in the storage device, wherein, when thedetermined direction is not forward, the in-place updating includes:deriving, from the update package, a roll-back sequence comprisingreverting update commands wherein at least two reverting update commandsin the derived roll-back sequence are ordered in an opposite order tothe particular order of the update commands in the update package; androlling-back the stored version to the original version by applying theroll-back sequence and utilizing reserved content when there has been aprior forward updating, and wherein at least one of the reverting updatecommands corresponds to a specified update command that is associatedwith a specified result and reverts the specified result of thespecified update command.
 2. The method of claim 1, wherein the storedversion is one of the following: an original version, an updated versionand an intermediate version.
 3. The method of claim 1, wherein theupdate package includes update commands, each update command is one ofthe following: a copy update command, a delete update command, an insertupdate command and replace update command.
 4. A method of in-placeupdating a stored version of content stored in a storage device using anupdate package that is adapted to update an original version of contentto an updated version, the method comprising: determininq a direction offthe updating; forward-updating the stored version to the updatedversion, when the determined direction is forward, wherein theforward-updating uses update commands included in the update packageaccording to a particular order, wherein the forward-updating furtherincludes reserving content when content is being deleted during thein-place updating, wherein reserved content is stored in segments ofphysical blocks in the storage device; and rolling-back the storedversion to the original version, when the determined direction is notforward, wherein the rolling-back uses reverting update commands derivedfrom the update package and wherein at least two derived revertingupdate commands are used in a reversed order and in view of the reservedcontent, when content has been reserved by a previous forward update,and wherein at least one of the reverting update commands corresponds toa specified update command that is associated with a specified resultand reverts the specified result of the specified update command.
 5. Asystem for in-place updating a stored version of content stored in astorage device using an update package, wherein the update package isadapted to update an original version of content to an updated version,wherein the update package includes update commands in accordance with aparticular order, the system comprising: a direction determination unitadapted to determine direction of the in-place updating; a forwardupdating processor coupled to the direction determination unit andadapted to forward-update the stored version to the updated version inaccordance with the particular order, when the determined direction ofthe updating is forward, and wherein the forward updating processor isfurther adapted to operate in accordance with the update commandsincluded in the update package and to reserve content deleted during thein-place updating, wherein reserved content is being stored in segmentsof physical blocks in the storage; a roll-back sequence deriving unitcoupled to the direction determination unit adapted to obtain from theupdate package, a roll-back sequence comprising reverting updatecommands wherein at least two derived reverting update commands are inaccordance with an order opposite to the particular order of the updatecommands in the update package, when the determined direction of theupdating is not forward; and a roll-back updating processor coupled tothe roll-back sequence deriving unit adapted to roll back the storedversion to the original version in accordance with the roll-backsequence, wherein the roll-back updating processor is further adapted tooperate in accordance with update commands included in the roll-backsequence and in accordance with the reserved content, wherein at leastone of the reverting update commands corresponds to a specified updatecommand that is associated with a specified result and reverts thespecified result of the specified update command.
 6. The system of claim5, wherein the direction determination unit is configured to determinethe direction in accordance with a direction indication.
 7. The systemaccording to claim 5, wherein the stored version is one of a groupincluding an original version, an updated version and an intermediateversion.
 8. A system for in-place updating a stored version of contentstored in a storage device using an update package, wherein the updatepackage comprises a sequence of update commands in a particular orderand is adapted to update an original version of content to an updatedversion, the system comprising: a direction determination unit adaptedto determine direction of the updating; a forward updating processorcoupled to the direction determination unit adapted to forward-updatethe stored version to the updated version when the determined directionis forward, the forward updating processor is adapted to update thestored version in accordance with update commands included in the updatepackage and in accordance with the particular order, and wherein theforward updating processor is further adapted to reserve content thathas been deleted during the in-place updating, in segments of physicalblocks in the storage device; and a roll-back updating processor coupledto the direction determination unit adapted to roll-back the storedversion, when the determined direction is not forward, the roll-backupdating processor is further adapted to update the stored version inaccordance with reverting update commands derived from the updatepackage, wherein at least two derived reverting update commands are inan order opposite to the particular order and in accordance with thereserved content, in case of a prior forward update, and wherein atleast one of the reverting update commands corresponds to a specifiedupdate command that is associated with a specified result and revertsthe specified result of the specified update command.
 9. A method ofin-place updating of a current version of content currently stored on astorage device with an updated version of the content, wherein thein-place updating results in overwriting of segments of physical blocksof the storage device which store the current version, with the updatedversion, throughout the updating, the method comprising: providing anupdate package including a sequence of update commands in a first order,wherein the package does not include reverting update commands in anorder other than the particular order; providing a direction indicationof either forward in-place updating or rollback in-place updating;performing in-place forward updating, when the indication is forward, byexecuting the update commands in accordance with the first order whilereserving content deleted throughout the execution of the forwardin-place updating; performing rollback in-place updating, when theindication is rollback, by: deriving from the update package a sequenceof reverting update commands in a second order wherein in the secondorder, at least two reverting update commands are in accordance with anopposite order to the first order, and executing the reverting updatecommands in accordance with the second order utilizing reserved contentthat has been reserved in case of a prior forward updating, wherein atleast one of the reverting update commands corresponds to a specifiedupdate command that is associated with a specified result and revertsthe specified result of the specified update command, and wherein thereserved content is stored in segments of physical blocks in the storagedevice.
 10. The method according to claim 9, wherein the providing ofthe direction indication is enabled throughout the in-place updatingmore than once.
 11. The method according to claim 1, wherein thedetermining of the direction of the in-place updating is enabledthroughout the in-place updating more than once.